REPUBLIQUC FRANCAI8E 



im 



PCT/iBOi / Q 2 6 2 5 
•C t I 08.0^). 



LAPnOPRIETE 

INDUSTRIELLE -~ ■ ■ ., , 

fwipo 



POT 



BREVET D'INVENTION 



CERTIFICAT D'UTILITE - CERTIFICAT D'ADDITION 



COPIE OFFICIELLE 

Le Directeur general de I'Institut national de la propriete 
industnelle certifie que le document ci-annexe est la copie 
certlfi^ei eonforme d'une demande de titre de propriete 
industrielle deposee a I'Institut. 



Fait d Paris, le . 



2 3 JUIL. 2004 



PRIOiUTY 
DOCUMENT 



Pour le Directeur g6n6ral de I'Institut 
national de la propri^tS industnelle 
Le Chef du D6partement des brevets 




Maitine PUNCHE 




I^PI 



■ IMSTtrOT 
HATtOUAL OB 
LAPROpaiETE 
INDU»TRlBLLe 



BREVET D'INVENTiON 
CERTIFICAT D*UTILITE 

Code de la propri£t6 intellectuelle - Lfvre VI 



N' 11354*03 



26 bis, rue de Saint P^tersbourg 
75800 Paris Cedex 08 

T6l6phone : 33 (1) 53 04 53 04 T^lteople : 33 (1) 42 94 86 54 



DATE 
UEU 



[6 a unpTI 



75 INPl PARIS 



N« O'ENREGISTREMENT 
NATIONAL OTiraBUe PAR fINPI 

DATE DE D£PdT ATTOIBUfeE 
PARUINPl 



03090D3 



2 3 Jllll. 2003 



Vos references pour ce dossier 

(faculkttif) BIF023426 - HST/AR 



REQUETE EN DELiVRANCE 
page 1/2 

Get imprim6 est h rempllr lisiblement a Tencre noire 

Q NOM ET ADRESSE DU DEMANDEUR OU DU MANDATAIRE 
A QUI LA CORRESPONDANCE DOIT EIRE ADRESSEE 



BRl 



DB $40 e tt / 210502 



SANTARELLI 

14, avenue de la Grande ArmSe 
75017 -PARIS 



Confirmation d'un depot par telecopie 


□ attribuS par riNPI d la telecopie | 




Cochez I'uiie des 4 cases suivantes | 


Demande de brevet 


m 1 


Demande de certifrcat d'utilitd 


□ - - — 1 


Demande divisionnaire 

Demande debrevainUiale 
otidemande decetiipceUdHdilUiiniHaie 


□ 

N- Date 1 1 1 . 1 1 1 . 1 

N° Date 1 1 i 1 1 1 1 1 1 1 


Transformation d'une demande de 
brevet europ6en Demande de brevet initiale 


U :■- 

N» Date 1 . 1 .[ ... 1 1 


g TITRE DE L'INVENTION (200 caracteres ou espaees maximum) 1 

Document de description d'un service propose par un serveur d'un r6seau de communication et precede de 1 
validation d'un document multimedia 1 


El DECLARATION DE PRIORITY 
OU REQUgTE DU BENEFICE DE 
LA DATE DE DEPOT D'UNE 
DEMANDE ANTCRIEURE FRANQAISE 


Pays OU organisation 1 
Datel 1 1 1 1 1 1 .| 1 NO 1 

Pays ou organisation 1 
Date 1 i 1 } 1 1 1 1 1 NO I 

Pays ou organisation r 1 
Date 1 f 1 I 1 I 1 1 1 NO j 

□ S'll y a d'autres priorites, cochez la case et utflisez I'imprime «Suite» | 


Bl DEMANDEUR (Cocliez rune 2 cases) 


la Personne morale □ Personne physique 1 


IMom 

00 denomination sociale 


CANON KABUSHIKI KAISHA 1 


Pr^noms 




Forme juridique 




N** SIREN 


Li 1 1 1 I 1 1 1 1 ~| 


Code APE-NAF 




1 . . 1 1 


Domicile 
ou 

$i6ge 


Rue 


3-30-2, Sliimomaruko, 3-chome. Ohta-ku 1 


Code postal et ville 


i . . . . 1 TOKYO ^ 1 


Pays 


JAPON 1 


Nationalite 


JAPONAISE ' J 


N** de telephone (facuitaUJ) 


N** de tei§copie (facuUatiJ) ] 


Adresse ^lectronique (facuUaliJ) 


□ S^il y a plus d'un demandeur, cochez la case et utilisez nmprim§ «Suite» 1 



Rempiir Imoeratlvement la 2^^ pagf> 



im 



uiritopRina 



BREVET D'INVENTION 
CERTIFICAT D'UTILIT^ 

REQUITE EN D^LIVRANCE 
page 2/2 




BR2 



I REMISI 

C PARIS 

(n«0*ENRE6ISTBEMENT 
I NATIONAL ATTRIBUe PAR L'INPI 



0309003 



MANDATAIRE {siiyaihuj 



Nom 
Pr^nom 



Cabinet ou Society 



N •de pouvotr permanent et/ou 
de lien contractuel 



OBS40W/2105(C 



SANTARELLI 



Adresse 



Rue 



14, avenue de la Grande Armee 




Les demandeurs et fes Inventeurs 
sont les mgm es personnes 



Etablissement imm^diat 
ou ^tablissement differ^ 



Paiement echelonn^ de la redevance 



I O REDUCTION DU TAUX 
OES REDEVANCES 



EJ3 SEQUENCES DE NUCLEOTIDES 
' ET/OU D'ACIDES AMIN ES 

Le support electronique de donn^es est joint 
La declaration de conformite de !a liste de 
support 6lectronique de denotes est jointe 
SI vous avez utilise rimprime ttSuite)i, 
fndiquez fe nombre de pages jointe s 
I EB SIGNATURE DU DEMANDEUR 
' OU DU MANDATAIRE 

(Nom et quaffte du signataire) 
Helena STANKOFF (98-0601) 



Les Inventeurs sont necessairement des personnes pl^il^ 



O Oul 

ja Non : Dans ce cas rempllr le f ormulafre de Designation dW nt.n.^ 
Onlquement pour une demande de lir&fet (y coniprls dlvjsia» etfiSi igfomata^r 
XJ " — ^ _ 



giquement pour ,es personnes physiques effecluarteUe^^ 

□ won 



Uniquement pour les personnes physiques 

U Obtenue anttneurement a ce d6p6t pour cette invention ^S^A /? 

□ cochezlacasesi la description contient une tiste de sequences 



□ 
□ 




VISA DE LA PREFECTURE 
OU DE L'INPI 




1 



La presente invention concerne un . document de description d'un 
service propose par un serveur d'un reseau de communication. 

Elle concerne 6galement un precede d'6Iaboration d'une requgte 
d'un service propose par un serveur d'un reseau de communication. 

Enfin. elle conceme un proc6d6 de validation d'un document 
multimedia ins§r6 dans un message destine ^ §tre echange sur Is reseau de 
communication lors de la mise en oeuvre d'un service propose par un serveur 
du reseau de communication. 

Au sein d'un reseau de communication informatique du type Intemet 
des ordfnateurs-serveurs offrent de plus en plus souvent des services a d'autres 
ordinateurs. appalls ordinateurs-clients. de ce reseau de communication. 

En pratique. I'ordinateur-client envoie un message comprenant des. 
donn6es ^ I'ordlnateur-serveur qui traite ces donn6es et retoume un r§sultat..l - 
De tels services sont appel6s services-Web. ).. ■ ' 

Du fait de I'augmentation de ces services disponibles sur un r^s^au 
de communication, les protocoles d'echanges de donnees entre des 
ordinateurs sont fr6quemment standardises. 

Ainsi. le protocole SOAP est un protocole permettant d'echanger des 
infomnations structur^es au-dessus du reseau Internet. 

Selon ce protocole SOAP, les Informations echangees sont 
structurees au moyen de ballses XML (acronyms du terms anglais "extended 
Mark-up Langage"). 

SOAP est un protocole de communication qui pemiet d'acceder ainsi 
a des services distants. 

Cette norme SOAP definit la structure g6n6rale des messages 
echanges ainsi que des traitements devant gtre r6alis6s par un ordinateur 
envoyant ou recevant des messages SOAP. ■ 
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Un message SOAP est compose d'un ou plusieurs blocs, repartis en 
deux grandes categories : les blocs d'en-t§tes (en anglais "header"), 
encapsul6s dans une balise <header>. et des blocs de corps (en anglais 
"body"), encapsul6s dans une balise <body>. 

Par ailleurs. un message SOAP est transmis d'un ordinateur ^ un 
autre sur le reseau de communication par un protocole de communication tel 
que HTTP (acronyme du terme anglais "Hyper Text Transfer Protocol"). SMTP 
(acronyme du terme anglais "Simple Mail Transfer Protocol"), protocole utilise 
pour l'6change de courrier efectronique. ou encore le protocole FTP (acronyme 
du terme anglais "File Transfer Protocol"), protocole utllis§ pour le transfert de 
ficliiers. 

La couche qui permet d'interfacer SOAP avec ces differents 
protocols de communication est appel^e. en anglais, un "binding". 

L'application SOAP permet de transporter des donnees binaires. tels 
que des images, via une extension "SOAP + Attachment" qui peut utiliser des 
m^canlsmes tels que MIME ou DIME. 

On connait par ailleurs un langage de description d'un service 
informatique WSDL (acronyme du terme anglais "Web Service Description 
Langage") qui permet de d^crire des services Internet, et notamment des 
20 services definis par la nomne SOAP. 

Un document WSDL contient ainsi la llste des sen/ices offerts par un 
ordinateur-serveur d'un r6seau de communication. 

Ce langage WSDL est lui-m§me une application du langage de 
balisage XML. 

On trouvera une description du langage WSDL 1.1 sur le site 
informatique a I'adresse http.7/www.w3 nrq/TR/2Q01/NOTE-wsdl-2nni n.-^i 

En pratique, un document electronique de description d'un service en 
langage WSDL comporte deux parties. 

Une premiere partle, appelee "partie abstraite", est adaptee ^ d^crire 
les messages ^changes entre ordinateurs du r§seau de communication lors de 
la fourniture d'un service. 
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En particulier, cette premiere partle permet de definir le type de 
donn^es 6changees, le type de messages utilises lors de I'execution du 
service, ainsi que les operations mises en oeuvre, definies par les messages qui 
sont echang6s lors de I'execution du service. 
5 Une operation peut done §tre vue comma un service 6l6mentaire, lui- 

m§me implements par un ou plusieurs messages suivant une suite logique 
d'organisatlon des messages. 

Le document de description d'un service WSDL comporte Sgalement 
une seconde partie adapt6e ^ d6finir des. infonnatlons relatives ^ la 
10 transmission des messages sur le reseau de communication. 

EKe permet d'indiquer en particulier comment les messages sont 
encodes pour §tre transmis sur le reseau et quel protocole de communication 
est effectlvement utilise. 

La representation actuelie d'un document WSDL permet de 
15 representer de manidre satisfaisante les services offerts par un serveur d'un 
reseau de communication manipulant des donnees XML. En effet, dans ce cas, 
un document de description d'un service WSDL permet ^ un serveur du reseau 
de communication de decrire abstraitement les donnees XML 6changees gr§ce 
a des schemas XML definis dans la section "[type/]" de la description WSDL. 
20 Selpri la norme WSDL 1.1, un document de description d'un service 

WSDL permet theoriquement de decrire des echanges de messages 
comportant des donnees binaires, tels que des Images. gr§ce § I'extension 
MIME. 

L'exemple suivant illustre la syntaxe utilisee : 
<wsdl :types> 

</wsdl : types>- 

<message name="giveImageMsgl"> 

• <part name=" image " type="xsd: binary" /> 
<part name= "directory" type="tns :DirectoryType"/> 
</message> 

<portType name= " ImageManipulations " > 
<operat ion name= " addlmage " > 

<input messages" give ImageMsg" name =" image I nput"> 
</operation> 
< /port Type > 
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<binding> 

<operation name="addlmage"> 
< soap ; operation 
name= "http : //example . com/addlmage" /> 
< input > 

<miine : multipartRelated> 
<inime :part> 

<soap:body parts=" directory" 

use="litteral"/> 

</mime :part> 
<mime :part> 

<minie : content part="imaqe" 
type= " image /qi f " / > ^ 

< /mime: part > 

</mime :multipartRelated> 
</ input> 

</operation> 
</binding> 

On constate ainsl que dans la partie abstraite de definition du 
message "givelmageMsgl", ce message est d^fini comme Tunlon de deux 
parties, une premiere partie "innage" correspondant ^ une Image et une 
deuxl^me partie "directory" correspondant & des donn6es XML. 

Un type "xsd:blnary" est donn§ k la partie "Image". Ce type est 
cependant rell§ ^ la serialisation utills^e et n'a pas de veritable signification : II 
s'agit en fait d'un tableau de valeur binaire. 

Dans la seconde partie du document WSDL, ce message est 
serialise au niveau protocolaire sous la forme d'un message MIME "multipart" 
dont la premiere partie correspond aux donnees XML et la deuxieme partie 
correspond ^ I'image. 

Cette deuxieme partie prend la fonne d'un attachement MIME du 
type "image/gif . 

Ainsl. lorsqu'un setveur et un client du reseau de communication 
souhaitent echanger des contenus multimedlas. tels que des images, outre 
d'eventuelles donnees XML. le document de description d'un service WSDL ne 
permet pas de decrire de maniere abstraite ces contenus multimedlas. 

Un document de description d'un service WSDL permet seulement 
de decrire I'echange de donnees multimedlas via I'extension "mime". Cette 



extension d^finit uniquement le format de transml?slon du contenu multimedia, 
en donnant le type "mime" du document tel que : image/jpeg. video/mjpeg4... 

. La pr6sente invention a pour but de resoudre les Inconvenients 
pr6cit§s et de proposer un document de description d'un service donnant la 
possibility d'effectuer des descriptions d'un contenu multimedia, de la mdme 
mani§re que des donn^es XIVIL. 

A cet effet, la presente Invention vise selon un premier aspect un 
document de description d'un service propose par un serveur d'un r6seau de 
communication comprenant une premldre partie abstraite adaptee ^ decrire au 
moins un message 6chang§ sur le r6seau de communication lors de la mise en 
oeuvre d'un service et une seconde partie concrete adaptee S d6crire les 
infonmations relatives a la transmission des messages sur le r§seau de 
communication. 

Selon rinvention, ce docunient de description d'un sen/ice comprend 
dans la premiere partie abstraite une description de contraintes abstraites 
associ§es k un document multimedia binaire. 

AinsI, le document de description d'un service ne decrit pas 
directement le contenu multimedia, sous la fomne d'un tableau de valours 
binaires, mais comporte une description de contraintes assoclees a ce 
document. 

Cette description de contraintes abstraites pennet de deflnir 
differentes contraintes applicables d un document multim§dla. telles que par 
exemple une taille maximale dlmage en nombre de pixels. 

II est ainsi possible dans la partie abstraite du document de d^finir un 
message Incluant line r6f§rence vers cette description de contraintes abstraites. 

Un tel message est ainsi adapts S contenir un document multimedia 
binaire, dds lors que document repond aux contraintes abstraites d6crites dans 
le document de description d'un service. 

Selon une caract6ristique pr§fer6e de I'invention, la description de 
contraintes abstraites est representee a partir de la s6mantique d'un langage de 
description d'un contenu d'un document multimedia binaire. ' 
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II est en effet avantageux d'utlllser une s6mantlque dm accessible 
et d6finie pour decrire Is oontenu d'un document multimedia binaire. 

Dans un mode pref6r6 de Tinvention, cette description de contraintes 
abstraites est representee d partir de la semantique definie par la norme 
MPEG7. 

En effet. cette norme MPEG7 est une norme de description de 
contenu multimedia, cette norme 6tant flexible et extensible. 

Les descripteurs et les schemas de description selon la norme 
MPEG7 sont adaptes ^ d§crire des contenus multim6dias. En pratique, un 
descripteur prend en entr6e un document multimedia et g6ndre un document 
XML. Ce document XML respecte la syntaxe definie par le schema de 
description MPEG? associ6 et donne les caracteristiques du document 
multimedia vIs-a-vIs du descripteur cholsl. 

On peut ainsi utillser cette description du document multimedia selon 
la norme MPEG7 pour inclure celle-ci dans un document de description d'un 
service conforme a invention, afin de decrire des contraintes abstraites 
associees au document multimedia. 

De maniere pratique, la description de contraintes abstraites est 
inseree dans une sous-partie de la premiere partle abstraite adaptee d decrire 
20 une structure abstraite des messages echanges. 

Cette description de contraintes abstraites peut aInsi etre utilisee de 
la m§me maniere que dans le cas des donn6es XML. definie dans une sous- 
partie "type" de la premiere parUe abstraite du document de description d'un 
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service. 



Cette premiere partie abstraite comporte en outre une deuxieme 
sous-partie adaptee ^ declarer au moins un message ei6mentaire polntant vers 
la description de contraintes abstraites. 

Selon un second aspect de I'lnvention. elle conceme un procede 
d-eiaboration d'une requete d'un sen/ice propose par un serveur d'un reseau de 
communication, le service etant decrit dans un document de description d'un 
service conforme a I'lnvention. 
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Ce proced6 d'elaboration d'une requ§te comprend les 6tapes 

suivantes : 

lecture du document de description d'un service ; 

- selection d'une premiere partie abstralte adaptee a decrire au 
5 moins un message echang6 sur le reseau de communication lors de la mise en 

oeuvre d'une operation associee au service ; 

extraction d'une description de contraintes abstraites associees a 
un document multimedia binaire ; 

- selection d'un document multimedia binaire en fonction de la 
10 description de contraintes abstraites ; et 

- elaboration d'une requSte a destination du serveur du reseau de 
communication incluant le document multimedia binaire seIectionn6. 

Grace au document de description d'un service conforme a 
rinvention, il est possible d'elaborer une requ§te integrant un document 

15 multimedia binaire selectionne en fonction de la description de contraintes 
abstraites Inseree dans le document de description d'un service. 

II est ainsi possible d'elaborer urie requete sur un reseau de 
communication permettant I'echange de donnees multimedias a partir de 
contraintes definies par un serveur via un document de description d'un service,. 

20 Selon un troisieme aspect de invention, elle conceme un precede 

de validation d'un document multimedia insere dans un message destine ^ §tre 
6change sur le reseau de communication lors de la mise en oeuvre d'un service 
propose par un serveur de ce reseau, le service etant associe § un document 
de description d'un service. 

25 Selpn I'lnvention, ce proc6de de validation comprend les etapes 

suivantes : 

- extraction du document multimedia lns§r§ dans le message ; 

- extraction d'une description de contraintes abstraites associees ^ 
un document multimedia binaire ^ partir du document de description d'un 

30 service ; 

extraction d'une description de contenu associee au document 

multimedia ; et 
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- comparaison de la description de contenu et de la description de 
contralntes abstraites extraite du document de description d'un service. 

Le document de description d'un service conforme a I'invention est 
ainsi utilise pour vallder un message avant ou apres son transfert sur le reseau 
de communication, en fonction de sa description. 

Grace a I'invention, un message peut §tre valld6 non seulement au 
niveau du contenu des donn^es XML. mais egalement au niveau du contenu 
des donnees binaires. associe a un document multimedia. 

Selon une caract§ristique pr6fer6e de I'invention, ce proc§d6 de 
validation est mis en ceuvre lors d'une 6tape de selection d'un document 
multimedia ^ inserer dans un message echange lors de la mise en ceuvre d'un 
service propose par un serveur de communication. 

Ce precede de validation peut aInsI §tre mis en ceuvre au niveau 
d'un ordinateur client, lors de I'eiaboration d'une requete induant un ou 
plusieurs messages ^ destination du sen/eur. II permet de s'assurer que le 
document multimedia adresse au serveur pourra effectivement etre utilise par 
ce serveur pour la mise en ceuvre du service propose. 

Parailelement. ce procede de validation conforme a I'invention peut 
egalement etre mis en ceuvre lors de la validation d'une requete re9ue par un 
serveur d'un reseau de communication pour la mise en ceuvre d'un service 
decrit dans un document de description d'un service. 

Ainsi, il est possible au niveau d'un sen/eur du reseau de 
communication de vallder une requete induant un ou plusieurs messages ayant 
un contenu multimedia, avant I'executlon du sen/Ice et I'utlllsation notamment 
de ce contenu multimedia. 

La presente invention conceme egalement un dispositif d'elaboration 
d'une requete d'un service propose par un serveur d'un reseau de 
communication, le service etant decrit dans un document de description d'un 
sen^ice conforme d I'invention. 

Ce dispositif d'elaboration d'une requete comprend : 

- des moyens de lecture du document de description d'un service ; 



- des moyens de selection d'une premiere partie absfraite adaptee 
^ d^crire au moins un message 6chang6 sur ie r6seau de communication lors 
de ia mise en oeuvre d'une operation associee au service ; 

- des moyens d'extraction d'une description de contraintes 
abstraites associees a un document multimedia binaire ; 

- des moyens de selection d'un document multimedia binaire en 
fonction de la description de contraintes abstraites ; et 

I 

- des moyens d'elaboratlon d'une requ§te ^ destination du serveur 
du r6seau de communication Incluant Ie document multimedia binaire 
s6lectlonn6. 

Elle concerne 6galement un dispositif de validation d'un document 
multimedia Ins6r§ dans un message destine d §tre echange sur Ie r6seau de 
communication lors de la mise en oeuvre d'un service propose par un serveur 
du r6seau de communication, Ie service etant associd a un document de 
description d'un service. 

Ce dispositif de validation comprend : 

- des moyens d'extraction du document multimedia insere dans Ie 

message ; 

- des moyens d'extraction d'une description de contraintes 
abstraites associ6es § un document multimedia binaire ^ partir du document de 
description d'un service ; 

- des moyens d'extraction d'une description de contenu associee 
du document multimedia ; et 

- des moyens de comparaison de la description de contenu et de 
la description de contraintes abstraites extraite du document de description d'un 
service, 

Ces dispositifs d'elaboration d'une requ§te et de validation d'un 
document multimedia presentent des caracteristiques et avantages analogues ^ 
ceux des precedes qu'ils mettent en ceuvre. 

La presente invention concerne 6galement un ordinateur serveur 
d'un reseau de communication comprenant des moyens adaptes ei mettre en 
oeuvre un precede de validation conforme d I'invention. 
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Elle cxDncerne 6galement un ordinateur client d'un. reseau de 
communication comprenant des moyens adapt^s ^ mettre en oeuvre le precede 
d'elaboration d'une requite d'un service confomie ^ I'invention et le precede de 
validation confomie d invention. 

Plus generalement. la presente invention conceme un r§seau de 
communication adapte a mettre en ceuvre les precedes decrits ci-dessus selon 
les differents aspects de I'invention. 

Elle conceme en outre un moyen de stockage d'infomiatlons 
eventueliement totalement ou partiellement amovible. lisible par un systeme 
informatique. comprenant des Instmctlons pour un programme Infomiatlque 
adaptees ^ mettre en oeuvre les proc6des d^crlts precedemment selon les 
d.fF6rents aspects de la presents Invention, lorsque ce programme est charge et 
ex6cut6 par le systeme informatique. 

Enfin. elle conceme un programme d'ordinateur lisible par un 
microprocesseur. comprenant des portions de code loglclel adaptees a mettre 
en ceuvre les proc6d6s decrits precedemment selon les differents aspects de la 
presente invention, lorsque ce programme d'ordinateur est charg6 et execute 
par le microprocesseur. 

Ces ordinateur-serveur. ordlnateur-client. r§seau de communication 
moyen de stockage d'informations et programme d'ortfinateur pr6sentent des 
caracterisUques et avantages analogues ^ ceux des proc6d6s qu'lls mettent 

oeuvre. 

D'autres particular's et avantages de I'invention apparaTtront 
encore dans la description cl-apr^s. 

Aux desslns annexes donn6s ^ titre d'exemple non limitatif : 

- la figure 1 est un algorithme lllustrant le proced§ de validation 
conforme ^ mode de realisation de I'invention ; 

- la figure 2 est un algorithme lllustrant le precede d'elaboration 
d-une requete d'un service conforme a un mode de realisation de I'invention ; 

- la figure 3 est un algorithme lllustrant I'execution d'une requite 
d'un service regu par un serveur d'un riseau de communication ; et 
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- la figure 4 est un schema-bloc illustrant un ordinateur adapte ^ 
mettre en oeuvre {'invention. 

On va decrire tout d'abord la structure d'un document de description 
d'un service conforme a un premier aspect de I'invention. 

On se place dans le cas de figure dans lequel un ordinateur-client C 
et un ordinateur-serveur S d'un r6seau de communication souhaltent §changer 
des contenus multimedias, en plus d'6ventuelles donn§es XML. 

On connatt d6j^ des documents de description d'un service WSDL 
donnant la possibility de decrire des types de messages §chang6s sur le 
r6seau de communication lorsque ces messages comportent des donnees 
XML. 

Le document de description d'un service conforme a I'invention offre 
la possibility de faire une description de type de documents multimedias comme 
pour des donnees XML. 

On rappelle qu'un document de description d'un sen/ice WSDL 
comprend une premiere partie abstraite adaptee ^ d6crire les messages 
echanges sur le reseau de communication lors de la mise en oeUvre du service 
et une seconde partie concrete adapt6e S d6cnYe les informations relatives S la 
transmission des messages sur le r6seau de communication. 

Conform§ment § I'invention. le document de description d'un service 
am§lior§ comprend dans la premiere partie abstraite une description de 
contraintes abstraites associee 6 un document multimedia binaire. 

Ainsi, le document de description d'un service ne comprend pas 
directement le contenu multimedia, sous forme de valeurs binaires. mais une 
description de ces documents et des contraintes appliqu^es k ce document 

II est ainsi possible de faire une description de type de documents 
multimedias. de la m§me maniere que pour des donnees XML. 

Cette description de type de documents multimedias peut comporter 
les contraintes suivantes : • 

Image dont la taille est au maximum de 640 x 480 pixels ; 
Image en niveau de gris uniquement ; 
sequence video du film "titre" ; 
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Musique compos§e par "auteur" ; 

Document multimedia comportant dans ses donnees d'en-tete le 
nom de son cr§ateur... 

De preference, la description de contralntes abstraites est 
representee a partir de la s§mantiqu6 d'un langage de description d'un contenu 
d'un document multimedia binaire. 

II est ainsi possible d'utiliser un langage de description connu. et de 
preference un langage de description utilisant un langage de balisage du type 
XIVIL. 

Dans la suite de la description, on considdre la semantique definle 
par la norme MPEG7. 

Cette norme MPEG7 est une norme de description de contenu 
multimedia flexible et extensible. Elle definit un ensemble de metiiodes et 
d'outlls pour les differentes phases de la description des documents 
15 multlmedias. 

La nomie MPEG7 peut se separer en trois parties : 

- les descripteurs MPEG7 ; 

- les schemas de description MPEG7 ; et 
un langage de definition des descripteurs. 

Les descripteurs et les schemas de description MPEG7 permettent 
de decrire des contenus multlmedias. 

En pratique, un descripteur considdre en entree un document 
multimedia et genere en sortie un document XML. Ce document en langage de 
balisage XML respecte la syntaxe definie par le schema de description MPEG7 
25 associe au document. 

II donne les caracteristiques du document multimedia vis-a-vis du 
descripteur choisi. 

Le langage de definition du descripteur permet I'integration de 
nouveaux descripteurs a MPEG7 par la construction de nouveaux schemas de 
30 description. 

On donne ci-apres un exemple de description MPEG7 d'une image 
en niveau de gris et de taille egale a 365 x 452 pixels : 
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<Mpeg7 xmlns="urri:Tnpeg:rapeg7 : schema: 2 001" 

xml ns : xs i = h t tp : / / www . w3 . org/ 2 0 0 1 /XMLS chema - 
instance" 

xmlns : mpeg7=" urn: mpeg:mpeg7 : schema: 2001" 
xs i : schemaLocat ion= " urn : mpeg : mpeg7 : schema : 2 0 0 1 
Mpeg7-2001 .xsd" > 
<Description> 

<Mul t imedi aCont ent > 
< Image > 

<MediaInf drmation> 
<MediaProf ile> 
<interleave> 

<VisualCoding> 
<interleave> 
< Format 
href= 

" urn : mpeg : : Vi sualCodingFormat CS : 2 0 0 1 : 1 " 

col'orDomain= "grayscale" /> 
< Frame width="356" 

height^ "4 52 " /> 

</ interleave> 
</VisualCoding> 
</interleave> 
</MediaProf ile> 
</MediaInf ormation> 
</ Image > 
< /Mul t imedi aCont ent > 
</Description> 
</Mpeg7> 

Selon la pr6sente invention, on decrit dans le document de 
description d'un sen/ice non pas directement le contenu multimedia mais le 
document MPEG7 con-espondant k ce contenu. 
5 En pratique, cette description de contraintes abstraites. est inseree 

dans une sous-partie de la premiere partie abstraite du document de 
description d'un service, cette sous-partie etant adaptee a decrire une structure 
abstraite des messages echanges, 

Cette description de contraintes abstraites est ainsi placee a 
10 rinterieur de la balise [wsdhtypes] du document de description d'un service. 

II est ainsi possible de d6crire des types de document multimedia de 
maniere similaire au langage XML-Schema utilise pour des dOnn6es XML. 
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L'jnt6r§t de r6utiliser les s§mantlques de la norme MPEG7 reside 
dans le fait que cette norme est tres complete, cx^nnue et tr^s comprise sur le 
r^seau de communication et support6e par de nombreux outlls de validation. 

En outre, une description selon la norme MPEG7 peut etre incluse 
directement dans un document multimedia. L'accds a cette description MPEG7 
est simplifi§ des lors que Ton possede ce document multimedia. 

Un document MPEG7 est un document repr6sentant un langage de 
balisage XML qui peut 6galement etre d6crit au moyen de sch6mas XML. 

Pour decrire un contenu multimedia, il est n§cessalre de decrire le 
type de description MPEG7 que peut prendre le document multimedia. 

En pratique, un schema XML est ecrlt. la description MPEG7 
associee a une image etant validee ou non en regard de ce schema XML. 

On notera qu'il est possible d'obtenir plusieurs descriptions MPEG7 
pour un meme document multimedia, des lors que de nombreux outlls 
d'extraction de caracteristiques d'Image existent et qu'une description MPEG7 
peut en Inclure plusieurs ou en inclure differentes informations. 

La description de contraintes abstraites inseree dans le document de 
description d'un service conforme a I'invention doit done decrire I'ensemble 
minimal de contraintes que doit respecter une description MPEG7. 

A cet egard. selon un premier mode de realisation de I'lnventlon la 
description de contraintes abstraites est mpresentee dans un langage de 
schema tel que "Schematron". Ce langage est adapte a deflnir un ensemble de 
contraintes minimales. 

II est ainsi possible de deflnir un schema sufflsamment souple pour 
donner un ensemble de contraintes minimales sans obliger le document 
multimedia a ne contenir que cet ensemble. 

Le langage "Schemafron" definit un ensemble de lois : une loi relie 
un ou plusieurs nceuds XML (specifle parXPath). un test booleen et un resultat 

Blen que molns connu que les langages de schema XML-Schema et 
Relax-NG. le langage Schematron pemiet une validation directe d'un document 
multimedia au regard des contraintes abstraites ainsi definies par ce langage 



15 

On donne cl-apr§s un exemple de description d'un contenu 
multimedia ^ I'aide de ce langage Schematron ^ I'int6rieur d'un 6l6ment "wsdl : 
type" d'un document de description d'un service : 

<wsdl : types > 
<ach : schema 

xmlns : sch="http : //www. ascc . net /xml /schematron" > 
<sch: pattern nanie= " MylmageType " > 
<sch:rule context="Mpeg7"> 

<sch: assert test= "count (Description) &gt ; 1 "/> 
</sch:xxile> 

< s ch : rul e cont ext = " Mpeg7 /Des crip t ion " > 

<sch: assert test="count (Collection) = l"/> 
</sch:rulb> 

, <sch : rule context="Mpeg7 /.../Frame" > 

<sch:assert test="®width > 0 and ©width 

&:lt; 640 "/> 

</sch:rule> 

<sch.-rule cont ext ="Mpeg7/.../ Format "> 

<sch:assert test="®colorDomain =' grayscale • "/> 
</sch:rule> . 

</sch:pattern> 
</sch: schema> 
< /wsdl : types > 

Selon un second mode de realisation de I'invention, !a description de 
5 contraintes abstraites est representee dans le document de description d'un 
service dans un langage de schema tels que XIVIL-Schema ou Relax-NG, les 
balises etant definies ^ partir de la semantique de la norme iVIPEGZ. 

L'utilisation de ces langages XML-Schema ou Relax-ISK3 presente 
I'avantage de permettre de definir alsement I'arborescence d'un document XIVIL. 

Dans cette arborescence, les contraintes abstraites a definir peuvent 
ne concemer qu'un sous-arbre XML du document XML complet. 

A titre d'exemple non limitatif, il est possible par exemple de 
contraindre unlquement la largeur d'une image et non pas sa hauteur. 

La nonne MPEG7 definit deux attributs "width" et "height" pour un 
15 element "image". 

De preference, le document de description d'un service ne definira 
que I'attribut "width" pour I'eiement "image" puisque I'attribut "height" n'a pas de 
contraintes. 
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Cette description pourra se presenter de la manlere suivante : 
<wsdl : types > 

<grammar ^mlns="http://relaxng.org/ns/structure/l 0"> 
<define name= " M>^F rameType " > 
< e 1 ement name = " Frame " > 

<attribute name=:"width" > 

<data type="tns:MySizeType"> 

<param name-"maxlnclusive" >640</param> 

<param name="minExclusive" >0</param> 
</aata> 

</attribute> 

</ element> 

</def ine> 

<define name= " MylmageTyiDe " > 
<element name="Mpeg7"> 

<element name="VisualCoding"> 
<interleave> 

<element name= " Format " > 

<attribute name«"colorDomain"> 

<value>grayscale</value> 
</attribute> 
< /el ement > 

<ref name= " MyFrameType " / !> 
</interleave> 
</element> 

</ element > 
</def ±ne> 
< /grammar > 
</wsdl : types > 

L'utilisation d'une telle syntaxe rend necessaire la definition d'un outil 
de validation specifique, lorsque I'on cherohe ^ valider un contenu multimedia 
au regard de la description d'un service conforme S invention. 

En partlculier. il est n6cessalre de creer un outil de validation etendu 
permettant de valider un document par un schema si Tun de ces sous-arbres 
est vaiid6 au sens classique. 

Get outll de validation etendu peut §tre impI6mente de differentes 

fa9ons. 

Une premiere solution consiste ^ effectuer una transformation XSLT 
qu. transfomne le schema tel que d6crit ci-dessus en un schema tel que 
Schematron adapts ^ definir des contraintes minimales. 
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Cette transformation XSLT ajouterait au schema initial des Elements 
pour rendre le schema ouvert et permettre la validation d'un document 
multimedia au regard de la description de contraintes abstraites. 

Une seconde solution repose sur ['utilisation d'un outil de validation 
5 XML standard tel que defini cl-dessous : 
Faire 

RES = Validation (document/- schema) 

Si (RES ne contient pas d'erreur)- Test = 1 

Sinon Test = -1 

Si (RES contient une erreur du type 'element X non 
dgfini') 

Enlever element X et Test = 0 
Si (RES contient une erreur du type ^attribut Y non 
defini') 

Enlever attribut Y et Test = 0 
Tant que (Test =0) 
Si (Test = 1) Validation rSussie 
Sinon Validation echbuee . 

L'interet d'utillser un langage de schema tel que XML-Schema ou 

Relax-NG est d'utillser des descriptions de contenus multim§dias et de donnees 

XML relativement similaires. 

Une troisieme solution consiste ^ repr6senter la description de 
10 contraintes abstraites dans un langage de description d'un contenu d'un 
document multimedia, et de preference selon la norme MPEG7. 

Les balises sont alors adaptees a int^grer directement ou par 
reference des attributs represent6s dans un langage de balisage de schema tel 
que XML-Schema. 

15 On utilise alors directement les elements et attributs definis par la 

norme MPEG7 a Tinterieur du document de description d'un service. 

Si necessaire, on utilise le langage XML-Schema soit via un attribut 

du type "mpegitype", soit directement int6gre dans les elements MPEG7. 

L'exemple suivant illustre ['utilisation de la semantique MPEG7 dans 

20 cette troisieme solution : 

<xs : complexType name = " myFrameTy pe " > 
<xs : element name= " Frame " > 

<xs : complexType > ' 
<xs rattribute name="width"> 
<xs : simpleType> 

<xsd: restriction base="xsd: integer "> 
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<xsd:maxlnclusive value="640" /> 
<xsd:minExclusive value="0"/> 
</xsd : restriction> 
</xsd : simpleType> 
</xs : attribute> 
</xs : complexType> 
< /xs : e 1 ement > 
</xs : complexType> 
<Mpeg7 mpeg ; name= " MyImac?eTvpe " > 
<Description> ... 

<VisualCoding> 
<interleave> 
<xs : choice > 

<Format colorDomain= "grayscale" /> 
<Frame mpeg ; type= " tns : myFrameTvpe " / > 
</xs : choice> 
</interleave> 
</VisualCoding> 
... </Description> 
</Mpeg7> 

L'avantage de cette troisfeme solution est de presenter una syntaxe 
proche de MPEG7 et trds lislble. 

II est aiors n6cessaire comme precedemment d'utiliser un outil de 
validation specifique. II est egalennent possible comme precedemment d'utiliser 
un document XSLT de transformation, afin de transformer la syntaxe XML en 
un langage de schema tel que Schematron permettant rutilisation directe 
d'outils de validation standards. 

Une fois cette description reprenant las s6mantlques MPEG7 ins6ree 
dans la section "type" du document de description d'un service, on insure une 
reference vers cette description dans la premiere partie abstraite du document 
de description d'un service. 

Classiquement. cette premiere partie abstraite comporte une 
deuxi6me sous-partie "message" adapt6a ^ declarer les messages 
6l§mentaires echang^s lors de la mise en oeuvre du message. 

Dans cette deuxidme sous-partie. il existe au moins un message 
6lementaire pointant vers la description de contraintes abstraites. 

De pr^f^rence, ce message elementaire est associ6 ^ un attribut 
adapts a specifier si le message comporte un type de contenu multimedia 
binaire. 
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On donne ci-apr§s un exemple de document de description d'un 
service conforme k I'inventlon : 
<wsdl : types > 

<grammar xmlns=: "http : //relaxng . org/ns/st ructure/l • 0 " > 
<define name- " MylmageType " > 
...</define> 
< /grammar > 
</wsdl : types> 

<message name= " givelmageMsgl " > 

<part name=" image" type= " tns : MylmageType " 
mpeg : mult imedia= " true " /> 

<part name=" directory" type="tns :DirectoaryType" /> 
</message> 

<port Type name= " ImageManipulat ions " > 
<operat ion name= " addlmage " > 

< input message= " tnsgivelmageMsg/ " 
name= " image Input " > 
</operation> 
< /port Type > 
<binding> 

. <operation name=" addlmage "> 
<soap : operation 
name= " ht tp : //example . com/ addlmage " / > 
<input> 

<mime : mult ipartRelated> 
<mime:part> 

<soap:body parts="directorv" 

use="litteral"/> 

</mime:part> 
<mime:part> 

<mime : content part=:" image " 

type= " image/i peg " / > 

< /mime: part > 
</mime :multipartRelated> 
</input> 
</op^ration> 
</binding> 

Dans cet exemple. deux types de donnees sont definis 
"MylmageType" et "DirectoryType". Ges deux types sont references dans la 
structure du message de Top^ration "addlmage". 

Ce message est ainsi constitu6 de deux parties abstraites. La 
premiere partie. definit des donnees XML et pointe vers le schema 
"DirectoryType". II s'agit du m6canisme classrque defini par la'norme WSDL. 
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La deuxfeme partle d6flnit un contenu multimedia et pointe vers le 
schema "MylmageType". La distinction de type de contenu. entre donnees XML 
ou contenu multimedia, peut s'effectuer de deux fagons : 

- soit le schema points expllcite le fait qu'il decrive uniquement des 
5 contenus multlm^dias. Par consequent, la partle qui pointe vers ce schema 

correspond S un contenu multimedia. 

- soit le document de descripUon d'un senrioe explioite dalrement 
le fart que cette partie du message est un contenu multimedia, par exemple via 
un attrlbut "mpeg : mulHm^ia = "true- ou un attribut de type mine p^cisan, 

10 qu il s agit d'un document multimedia. 

Cette description de message fait ainsi partle d'une description 
d echange de messages entre un ordinateur-client C et un ortilnateur-serveur S 
La seconde partie concrete du document de description d'un service 
deilmltee par la balise "binding-, comporte des Informations de serialisation ' 
H est alors possible d'utillser des m^canlsmes classiques tels que 
DIME ou MIME. 

Cette seconde partie concrete ajoute les informations necessaires ^ 
renvoi du message sur le reseau. 

Dans i'exemple precedent, I'extension MIME de la norme WSDL est 
ut,I.see. L'image qui va transiter sur le reseau est done d6flnle de mani^re 
abstraite par le schema "MylmageType" et serialls^e sous la fomie d'un 
attachement MIME. 

Un tel document de description d'un service permet ainsi de decrire 
de maniere abstraite un contenu multimedia, de mani^re analogue ^ ce qui est 
25 connu pour des donnees XML. 

On peut alors utillser des mecanlsmes simllaires de validation d'un 
document multimedia, d'elabomtion et d'execution d'une requete d'un service 
sur un reseau de communication. 

30 validation d un document multimedia destine * «re ^ct,ang4 sur le reseau de 
communication lors de la mise en ceuvre d'un service, lorsque le sen,ice est 
assoc,6 a un document de description d'un sen/ice confbrme S I'lnvention 
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Une 6tape d'acqulsition E10 est tout d'abord mise en cEuvre pour. 
. acqu6rir un document multimedia, 

Lors de I'^laboration d'un message, par. exemple par un ordinateur- 
client C, cette etape d'acqulsition E10 peut consister S selectionner un 
document multimedia a insurer dans un message qui sera echange lors de la 
mise en oeuvre du service propose par le serveur de communication. 

Cette acquisition peut §tre faite ^ partir .d'une base de donn^es 
d'image par exemple. 

Lors de la validation d'un message reQu, par exemple par un 
ordin^teur-serveur S, cette 6tape d'acqulsition E10 consiste S extraire le 
document multimedia d'un message 6chang6 sur le reseau de communication. 

Une etape d'extraction E11 est ertsuite adaptee § extraire la 
description de contraintes abstraites Inser6e dans le document de description 
d'un service et reliee au document multimedia acquis a I'etape precedente. 

Une seconde etape d'extraction E12 est egalement adaptee ^ , 
extraire la description MPEG7 associee au document multimedia acquis. 

II est necessaire que I'ordinateur mettant en. oeuvre ce procede de . 
validation possede ies differents extracteurs MPEG7 adaptes S conslderer 
contenu multimedia en entree et a donner en sortie une description MPEG7. 

Ces extracteurs peuvent etre dedies e une description specrfique 
d'un document multimedia (extraction de la couleur domlnante d'une image par 
exemple). li peut aussi s'agir d'un programme qui va extraire une description 
IVIPEGT (binaire) deja contenue dans le document multimedia. 

Une etape de comparalson El 3 permet ensulte de comparer cette 
description MPEG7 e la description extraite du document de description d'un 
service conforme ^ I'lnventlon. 

On notera que la norme MPEG7 etant une norme extensible, il n'est 
pas possible de generer un document comportant toutes Ies descriptions 
possibles MPEG7 du document multimedia. 

Plusieurs solutions sont alors possibles pour mettre en oeuvre ce 
precede de validation, ' 
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Tout d'abord. j| est possible que I'ordlnateur mettanf en CBuvre ce 
procede de validation ne supporte qu'un sous-ensemble de la norms MPEG7 at 
est ainsl adapts a g^n^rer I'ensemble des Informations MPEG7 de ce sous 
ensemble dans un document en langage de bailsage XML. 

Bien que simple, cette m^thode ne profite pas de I'extensiblllt^ de la 
norme MPEG7, 

"^^'^S^'^™"' possible d'extraire 4 partirde la description ins^r^e 
dans la document d'un sewloa fensemble des ca,act^rist,<,ues du contenu 

multimedia. 

A I'tepe d'extraction E12 de la description MPEG7. on gSn^re aloi^ 
un document MPEG7 poss^ant toutes les caract^ristlques identifl.es . partir 
de la description du document WSDL. 

Cette methods n^cessKe la cr^aBon d'un outil de lecture de 
description MPEG7 et de g6n6rat,on d'un document MPEG7 sp^cifique 

lJ"«»°isi*™ solution est fondSesur una m^thode iterative a partir 
de louai de validation connu XML-Schema ou Relax-NG. En pratique un 

premier document MPEG7 est extrait a rstape d'extraction E12 

MPEG7. ""T? oomparalson E13 est adapts . valider ce document 
IVIPEG7 a parfir de la description du document WSDL. 

Si une erreur du type "element X missing" apparatt. » est n^ssaire 
d ajouter la caractSristique X au document MPEG7 

l.'«ape d'extraotion E12 est alore r^itSr^e pour extraire la 
cara^ristique X . partir du document mumm^ia et completer la description 

„nt. .-, "^T ^'^^ «»"l^raison E13 et d'extraction E12 sent rat^ries 
tant qu'il existe une erreur. 

Paire 

?r ^^^^^"^^^^"^ (document, schema) 
Test f <=o"tient pas d' erreur) 

Sinon 
Test = -1 

CAR = CaracteristiqueDe (X) 



23 

Aj outCaracteristique (CAR, document , X) 
Test = 0 
Tant que (Test = 0) 
Si (Test = 1) 

Validation r^ussie 
Sinon 

Validation 6chou^e 

On notera que de nombreux documents multimedias possddent una 
description MPEG7 binaire .et conripressee incorpor^e directement dans ce 
document. Cette description MPEG7 peut' §tre utilisee comma document de 
base pour le proc6d§ de validation, notamment la precede de validation iteratif 
5 , d^crit cl-dessus. 

Ce precede de validation d'un contenu multimedia peut s'appliquer 
notamment lors de la construction d'un message. 

On va decrire ainsi en reference d la figure 2 un proc6de 
d'elaboration d'une requ§te d'un sen/ice propose par un serveur d'un r^seau de 
10 communication, ce service 6tant decrit dans un document de description d'un 
service VVSDL confomie a Tinvention. 

Une 6tape de lecture E20 est d'abord mise en oeuvre pour lire ie 
document de description d'un service WSDL. 

Une 6tape d'extraction E21 est adapt^e a extraire une premiere 
1 5 partie abstraite du document WSDL adapt^e a d6crlre un message 6change sur 
le r6seau de communication lors de la mise en oeuvre d'une operation associee 
au service. 

En pratique, on seleotionne une operation et on extrait la" description 
abstraite associee a cette operation. 
20 Une etape d'extraction E22 est adapt6e 6 extraire la description de 

contraintes abstraltes associ6e d un document multimedia binaire qui devra 6tre 
Ins6r§ dans le message d destination du sen/eur, 

Une etape de selection E23 est ensuite adapt6e d s6lectionner un 
contenu multimedia en fonctlon de la description obtenue k I'etape d'extraction 
25 E22. 

En pratique, on seiectionne un contenu multlm6dPa en fonction des 
contraintes abstraites d6crites dans le document de description d'un service 
WSDL. 
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Lors de cette selection d'un contenu multimedia, le proc6de de 
validation decrit pr^c6demment en reference ^ la figure 1 peut etre mis en 
oBuvre. 

Une etape de test E24 permet de verifier si cette selection a reussi, 
c'est-^-dire si le document multimedia selectionne a ete valid6 a partir de la 
description d'un contenu multimedia. 

Dans la negative, une etape de generation E25 d'une erreur ^ 
destination du client est mise en oeuvre. 

SInon. une etape d'eiaboration E26 d'une requete correspondant i 
roperation cholsie. ^ destination du serveur du reseau de communication, est 
mise en oeuvre. 

Cette requete inclut le document multimedia binaire- selectionne ^ 
retape de selection E23. 

Cette requete est ensuite envoyee ^ un serveur pour I'execution lors 
de la mise en oeuvre du service propose par ce serveur. 

AInsi. lors de la construction d'un message, le precede de validation 
permet de s'assurer que I'image est valide. lors de la selection d'une image 
parmi plusleurs contenus multimedias. ou encore lors de la production d'un 
contenu multimedia. 

On va decrire ^ present en reference ^ la figure 3 la validation d'une 
requete regue par le serveur d'un reseau de communication. 

Lors de la reception du message. 11 s'agit pour le serveur ou pour un 
noeud .ntermediaire entre le client et le serveur sur le reseau de communication 
de s'assurer que le client a envoye un document multimedia tel que speclfie 
dans le document de description d'un service confomie ^ I'invention. 

Ce precede de validation d'une requete comporte tout d'abord une 
etape de reception E30 de la requete par un serveur, ou encore par un noeud 
intermediaire du reseau. 

Une etape de validation E31 est mise en CBuvre a partir du contenu 
30 de la requete. 
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Cette ^tape de validation E31 est identlque au proc6d6 de validation 
decrit prec6demment en reference ^ la figure 1, dans lequel l'6tape d'acqulsition 
E10 consiste ici ^ extraire un document multimedia insure dans la requete. 

Une 6tape de test E32 permet de verifier si la validation est reussle. 

Dans la negative, une etape d'envoi E33 d'un message d'erreur est 
mise en oeuvre a destination dii client. 

Si la validation est r^ussie, une 6tape d'executlon E34 de la requ§te 
est mise en ceuvre de manidre classique sur le serveur. 

Une §tape E35 d'envoi des r6sultats sous forme d'une r6ponse ^ 
Tordinateur-cllent est ensulte mise en oeuvre. 

La presente Invention permet ainsi de d6crire de mani^re abstraite 
des contenus multim6dias dans le cadre de services Web. il est ainsI possible 
de contraindre des donn6es multimedias qui seront echang^es lors de la mise 
en ceuvre d'un service, d'urie manidre analogue a celle utilisee pour echanger 
des donndes XML. 

Afin de mettre en oeuvre les proc6d6s de validation, d!elaboration 
d'une requete d'un service et d'executlon d'une requete d'un service, des 
dispositifs associes a ces proc6d6s peuvent §tre incorpores dans un ordinateur 
tel qu'illustr6 a la figure 4. 

En particulier, le dispositif d'6laboratlon d'une requ§te peut gtre 
lncorpor§ dans un ordlnateur-cllent C d'un r6seau de communication alors que 
le dispositif d'executlon d'une requ§te peut gtre lncorpor§ dans un ordlnateur- 
serveur S d'un r§seau de communication. 

Blen entendu, les dispositifs destines S mettre en oeuvre les 
differents precedes de la presente invention peuvent §tre mis en oeuvre dans 
un m§me ordinateur ou blen dans des stations differentes du r6seau de 
communication. 

En particulier, le dispositif de validation d'un document multimedia 
sera incorpore de preference a la fois dans un ordinateur-client C et dans un 
ordinateur-serveur S du reseau de communication. 

Plus precisement, les differents moyens adaptes ^ mettre en ceuvre 
les etapes des precedes conformes d Pinventlon peuvent etre Incorpores dans 
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un microprocesseur 100, une m6molre morte 101 ("Read-only memory" ou 
ROM) etant adaptee S m6moriser un programme de validation d'un document 
multimedia, d'^laboration d'une requ§te d'un service ou d'ex6cution d'une telle 
requite. 

Une m§moire vive 102 ("Random access memory" ou RAM) est 
adaptee a memoriser dans des registres les valeurs modifiees lors de 
rexecution du programme de validation d'un document multimedia, 
d'§laboration d'une requete d'un service ou d'ex6cution d'une telle requ6te. 

Le microprocesseur 100 est int§gr6 ^ un ordinateur qui peut §tre 
connecte a differents p6ripii6riques et ^ d'autres ordinateurs d'un r6seau de 
communication 10. En particulier, cet ordinateur correspond ^ un ordinateur- 
serveur S, un ordinateur-client C ou encore S un ordinateur intemi6diaire ^ un 
noeud de ce reseau de communication 10. 

Cet ordinateur S. C comports de manlere connue une interface de 
communication 110 relie au r6seau de communication pour recevoir ou 
transmettre des messages. 

L'ordinateur comporte en outre des moyens de stockage de 
documents, tel qu'un disque dur 106, ou est adapts ^ coop§rer au moyen d'un 
lecteur de disque 107 (disquettes. disques compacts ou cartes informatlques) 
avec des moyens de stockage de documents amovibles. tels que des disques 
7. Ces moyens de stockage fixes ou amovibles peuvent comporter le code des 
proc§des conformes S I'invention. 

lis sont egalement adapt6s ^ memoriser un document 6lectrx>nique 
de description d'un service tel que d6finl par la pr6sente invention. 

A titre de variante, ces programmes peuvent §tre stock6s dans la 
m§moire morte 101. 

En seconde variante. ces programmes pourront etre regus pour §tre 
stock^s comme decrit pr6c§demment par I'intemiediaire du reseau de 
communication 10. 

L'ordinateur S, C poss^de egalement un ecran 103 permettant par 
exemple de servir d'interface avec un operateur a I'aide du clavier 104 ou de la 
souris 105 ou de tout autre moyen. 
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L'unite centrale 100 (CPU) ex§cutera alors les instructions relatives a 
la mise en ceuvre de {'invention. Lors de ia mise sous tension, les programmes 
et m6thodes relatives ^ I'invention stoclces dans une m6moire non volatile, par 
exemple ia memoire 101, sont transf§res dans la memoire 102 qui contiendra 
5 alors le code executable de I'invention ainsi que les variables n^cessaires ^ la 
mise en ceuvre de I'invention. 

Le bus de communication 112 permet la communication entre les 
diff^rents sous-el§ments de I'ordinateur ou li§s d lul. 

La representation de ce bus 112 n'est pas limitative et notamment le 
10 microprocesseur 100 est susceptible de communiquer des instructions ^ tout 
sous-6lement directement ou par I'Intermediaire d'un autre sous-6l6ment. 

Bien entendu, de nombreuses modifications peuvent §tre apport^es 
aux exemples de realisation d§crits pr§c6demment sans sortir du cadre de 
I'invention. 

15 
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REVENDICATthMR 

1 . Document de description d'un sen/ice propose par un serveur (S) 
d'un r6seau de communication (10) comprenant une premiere partie abstraite 

5 adaptee a decn're au moins un message echange sur le reseau de 
communication (10) lors de la mise en ceuvre dudit service et une seconde 
partie concrete adaptee ^ decrire les informations relatives ^ la transmission 
desdits messages sur (e reseau de communication, caract6rise en ce qu'il 
comprend dans ladite premiere parOe abstraite une description de contraintes 
1 0 abstraites associees ^ un document multimedia binalre. 

2. Document de description d'un service, caract6ris6 en ce que 
ladite description de contraintes abstraites est representee a partir de la 
semantlque d'un langage de description d'un contenu d'un document 
multimedia binaire. 

3. Document de description d'un service, conforme a Tune des 
revendications 1 ^ 2. caracterise en ce que ladite description de contraintes 
abstraites est representee a partir de la semantique definie par la norme 
MPEG7. 

4. Document de description d'un service conforme ^ I'une des 
revendications 1 a 3. caracterise en ce que ladite description de contraintes 
abstraites est representee dans un langage de balisage du type XML. 

5. Document de description d'un service conforme k I'une des 
revendications 1 a 4. caracterise en ce que ladite description de contraintes 
abstraites est representee dans un langage de schema tel que XML-Schema ou 
Relax-NG. des balises etant definies S partir de la semantique de la nomie 
MPEG7. 

6. Document de description d'un service conforme ^ I'une des 
revendications 1 ^ 4. caracterise en ce que ladite description de contraintes 
abstraites est representee dans un langage de description d'un contenu d'un 
document multimedia. lesdites balises etant adapt6es a integrer directement ou 
par reference des attribute representes dans un langage de balisage de 
schema tel que XML-Schema. 
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REVENDICATIOMR 

1 . Document de description d'un service propos§ par un serveur (S) 
d'un reseau de comnnunication (10) comprenant une premiere partie abstraite 
adapt6e k d6crire au moins un message ^change sur le reseau de 
communication (10) lors de la mise en oeuvre dudit service et une seconde 
partie concrete adapt6e a d6crire les informations refatives a la transmission 
desdits messages sur le r6seau de communication, caract^rlse en ce qu'il 
comprend dans ladite premiere partie abstraite une description de contralntes 
abstraites associ6es a un document multimedia binaire. 

2. Document de description d'un service, caracteris§ en ce que 
ladite description de contraintes abstraites est representee a partir de la 
semantique d'un langage de description d'un contenu d'un document 
multimedia binaire. 

3. Document de description d'un service, confonrje k I'une des 
revendlcations 1 d 2. caracteris§ en ce que ladite description de contraifites 
abstraites est representee d partir de la semantique definie par la nomie 
MPEG7. 

4. Document de description d'un sen^ice conforme a Tune 'des 
revendlcations 1 a 3, caracterise en ce que ladite description de contraintes 
abstraites est representee dans un langage de ballsage du type XML. 

5. Document de description d'un service conforme' ^ I'une des 
revendlcations 1 ^ 4, caracterise en ce que ladite description de contraintes 
abstraites est representee dans un langage de schema tel que XML-Schema ou 
Relax-NG. des ballses etant definies a partir de la semantique de la norme 
MPEG7. 

6. Document de description d'un service confonne S I'une des 
revendlcations 1 d 4, caracterise en ce que ladite description de contraintes 
abstraites est representee dans un langage de description d'un contenu d'un 
document multimedia, lesdites ballses etant adaptees S Int^grer directement ou 
par reference des attributs representes dans un langage de balisage de 
schema tel que XML-Schema. 
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7. Document de description d'un service conforme a la 
revendlcation 6. caract6ris6 en ce que ie langage de description d'un contenu 
d'un document multimedia est d^fini selon la norme MPEG7. 

8. Document de description d'un service conforme a I'une des 
revendications 1 ^ 4. caracterise en ce que ladite description de contraintes 
abstraites est representee dans un langage de schema tel que Schematron 
adapte ^ definir un ensemble de contraintes minimales. 

9. Document de description d'un service conforme ^ I'une des 
revendications 1 a 8. caract6ris6 en ce que ladite description de contraintes 
abstraites est ins6r6e dans une sous-parUe de ladite premiere partie abstraite 
adaptee ^ d6crire une structure abstraite des messages 6chang6s. 

10. Document de description d'un service conforme a la 
revendlcation 9. caracteris6 en ce que ladite premiere partie abstraite comporte 
une deuxi^me sous-parbe adaptee ^ declarer au moins un message 
elementaire pointant vers ladite description de contraintes abstraites. 

11. Document de description d'un service conforme ^ la 
revendlcation 10. caracterise en ce que ledit message 6l6mentaire est associe 
a un attribut adapts ^ specifier que Ie message comporte un type de contenu 
multimedia binaire. 

12. Precede d'6laboration d'une requ§te d'un seivlce propose par un 
serveur (S) d'un r6seau de communication (10). ledit sen/ice 6tant decrit dans 
un document de description d'un service confomie ^ I'une des revendications 1 
a 1 1. caracterise en ce qu'il comprend les etapes sulvantes : 

- lecture (E20) dudit document de description d'un service • 

- selection (E21) d'une premiere partie abstraite adaptee a decrire 
au moins un message 6change sur Ie reseau de communication lors de la mise 
en oeuvre d'une operation associee audit service ; 

- extraction (E22) d'une description de contraintes abstraites 
associees a un document multimedia binaire ; 

- selection (E23) d'un document multimedia binaire en fonction de 
ladite description de contraintes abstraites ; et 
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7. Document de description d'un service conforme d ia 
revendication 6, caracteris6 en ce que le langage de description d'un contenu 
d'un document multimedia est defini selon la norme MPEG7. 

8. Document de description d'un service conforme d I'une des 
revendlcations 1 a 4, caract6ris6 en ce que ladite description de contraintes 
abstraltes est representee dans un langage de schema tel que Schematron 
adapte d d6finlr un ensemble de contraintes minlmales. 

9. Document de description d'un service confonne a I'une des 
revendlcations 1 § 8, caract6rise en ce que ladite description de contraintes 
abstraites est inser6e dans une sous-partie de ladite premiere partie abstraite 
adaptee ^ decrire une stmcture abstraite des messages echanges. 

10. Document de description d'un service conforme ^ la 
revendication 9, caracterise en ce que ladite premidre partie abstraite comporte 
une deuxieme sous-partie adapt6e a declarer au moins un message 
eiementaire pointant vers ladite description de contraintes abstraites. 

11. Document de description d'un service conforme S la 
revendication 10, caracterise en ce que ledit message eiementaire est associe 
§ un attribut adapte § specifier que le message comporte un type de contenu 
multimedia binaire. 

12. Precede d'eiaboration d'une requete d'un service propose par un 
serveur (S) d'un reseau de communication (10). ledit service etant decrit dans 
un document de description d'un service conforme a I'une des revendlcations 1 
^11, caracterise en ce qu'il comprend les etapes suivantes : 

-. lecture (E20) dudit document de description d'un service ; 

- selection (E21) d'une premiere partie abstraite adaptee ^ decrire 
au moins un message echange.sur le reseau de communication lors de la mise 
en oeuvre d'une operation associee audit service ; 

- extraction (E22) d'une description .de contraintes abstraites 
associees S un document multimedia binaire ; 

» - selection (£23) d'un document multimedia bi.riaire en fonction de 

ladite description de contraintes abstraites ; et 
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- Elaboration (E26) d'une requ§te ^ destination du serveur du 
r6seau de communication Incluant ledit document multimedia binaire 
selectionne. 

13. Procede de validation d'un document multimedia lors de la mise 
en oeuvre d'un service propose par un seiveur (S) d'un reseau de 
communication (10), le service etant associe a un document de description d'un 
service. caracteris6 en ce qu'il comprend les etapes suivantes : 

- acquisition (E10) du document multimedia ; 

- extraction (E11) d'une description de contraintes abstraltes 
associees a un document multimedia binaire ^ partir dudit document de 
description d'un service ; 

- extraction (El 2) d'une description de contenu associee audit 
document multimedia ; et 

- comparalson (E13) de ladite description de contenu et de la 
description de contraintes abstraltes extraite du document de description d'un 
service. 

14. Precede de validation conforme a la revendication 13, 
caracterise en ce que ladite description de contraintes abstraltes est 
representee dans un langage de description d'un contenu d'un document 
multimedia. 

15. Precede de validation conforme a I'une des revendications 13 ou 

14. caracterise en ce que le langage de description d'un contenu d'un document 
multimedia est defini sous la norme MPEG7. 

16. Precede de validation confonne a I'une des revendications 13 a 

15. caracterise en ce que § I'etape d'extraction (E12), une description MPEG7 
du document multimedia inseree dans ledit document multimedia est extraite. 

17. Precede de validation conforme a Tune des revendications 13 S 

16. caracterise en ce qu'il est mis en ceuvre lors d'une etape de selection (E23) 
d'un document multimedia gi inserer dans un message echange lors de la mise 
en oeuvre d'un service propose par un serveur du reseau de communication. 

18. Precede de validation conforme ^ Tune des revendications 13 ^ 
16. caracterise en ce qu'il est mis en oeuvre lors d'une etape de validation (E31) 
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- Elaboration (E26) d'une requete ^ destination du serveur du 
r6seau de communication incluant ledit document multimedia binaire 
selectionne. 

13. Proc§d6 de validation d'un document multimedia lors de la mise 
en oeuvre d'un service propose par un serveur (S) d'un r6seau de 
communication (10). le service etant decrit dans un document de description 
d'un service confomne d I'une des revendications 1^11. caract6rise en ce qu'il 
comprend les etapes suivantes : 

- acquisition (E10) du document multimedia ; 

- extraction (E11) d'une description de contraintes abstraites 
associees a un document multimedia binaire d partir dudit document de 
description d'un service ; 

- extraction (El 2) d'une description de contenu associee audit 
document multimedia ; et 

- comparaison (El 3) de ladite description de contenu et de la 
description de contraintes abstraites extraite du document de description d'un 
service. 

14. Precede de validation conforme d la revendicatlon 13, 
caracterise en ce que ladite description de contraintes abstraites est • 
representee dans un langage de description d'un, contenu d'un document 
multimedia. 

15. Procede de validation confomne a I'une des revendications 13 ou 

14, caracterise en ce que le langage de description d'un contenu d'un document 
multimedia est defini sous la norme MPEG7. 

16. : Procede de validation conforme a I'une des revendications 13 d 

15, caracterise en ce que a I'etape d'extraction (E12), une description MPEG7 
du document multimedia inseree dans ledit document multimedia est extraite. 

17. Procede de validation conforme d I'une des revendications 13 S 

16, caracterise en ce qu'il est mis en oeuvre lors d'une etape de selection (E23) 
d'un document multimedia d inserer dans un message ech^nge lors de la mise 
en oeuvre d'un service propose par un serveur du reseau de communication. 
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d'une requ§te regue par un serveur d'un r6seau de communication pour la mise 
en oeuvre d'un service decrit dans un document de description d'un service. 

19. DIspositif d'6laboration d'une requete d'un service propose par 
un serveur d'un r§seau de communication, ledit service 6tant d6crit dans un 
document de description d'un service conforme ^ I'une des revendications 1 
1 1 , caracterise en ce qu'il comprend : 

- des moyens de lecture (100. 101. 102) dudit document de 
description d'un service : 

- des moyens de selection (100. 101. 102) d'une premiere partie 
abstralte adapt^e a decrire au molns un message ^change sur le reseau de 
communication lors de la mIse en oeuvre d'une operation associee audit 
service ; 

- des moyens d'extraction (100. 101, 102) d'une description de 
contraintes abstraites assoctees a un document multimedia binaire ; 

- des moyens de selection (100, 101. 102) d'un document 
multimedia binaire en fonction de ladite description de contraintes abstraites ; et 

- des moyens d'§laboration (100. 101. 102) d'une requ§te ^ 
destination du serveur du reseau de communication Incluant ledIt document 
multimedia binaire selectionne. 

20. DIspositif d'elaboration d'une requdte d'un service confonne a la 
revendlcation 19. caracterise en ce qu'il est incorpor§ dans : 

un microprooesseur (100) ; 

- une m6moire morte (101) adapt6e d m^moriser un programme 
d'elaboration d'une requ§te d'un service ; et 

- une m§moire vive (102) comprenant des registres adaptes a 
m^moriser les variables modlfides lors de l'ex§cution dudit programme. 

21 . DIspositif de validation d'un document multimedia lors de la mise 
en oeuvre d'un service propose par un serveur d'un reseau de communication 
le sen/Ice 6tant associe ^ un document de description d'un service, caract6ris6 
en ce qu'il comprend : 

- des moyens d'acquisition (100. 101. 102) du document 
multimedia ; 
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18. Procede de validation conforme a I'une des revendications 13 a 
16. caracterise en ce qu'il est mis en oeuvre lore d'une 6tape de validation (E31) 
d'une requ§te re$ue par un serveur d'un r6seau de communication pour la mise 
en ceuvre d'un service d6crit dans un document de description d'un service. 

19. DIspositif d'elaboration d'une requ§te d'un service propose par 
un serveur d'un r6seau de communication, ledit service §tant d^crit dans un 
document de description d'un service conforme a I'une des revendications 1 ^ 
11, caracteris§ en ce qu'il comprend : 

- des moyens de lecture (100, 101, 102) dudit document de 
description d'un service ; 

- des moyens de selection (100. 101. 102) d'une premiere parOe 
abstraite adaptee ^ d^crirei au moins un message echang§ sur ie r6seau de 
communication lors de la mise en oeuvre d'une op6ratlon associ^e audit 
service ; 

- des moyens d'extraction (100. 101. 102) d'une description de 
contraintes abstraltes associees d un document multimedia binaire ; 

- des moyens de selection (100. 101. 102) d'un document 
multimedia binaire en fonction de ladite description de contraintes abstraites ; et 

- des moyens d'elaboration (100. 101. 102) d'une requ§te a 
destination du serveur du reseau de communication incluant ledit document 
multimedia binaire selection ne. 

20. Disposltif d'6laboration d'une requ§te d'un service confonne a la 
revendication 19, caracterise en ce qu'il est incorpore dans : 

T un microprocesseur (100) ; 

- une memoire morte (101) adapt6e a m§moriser un programme 
d'elaboration d'une requ§te d'un service ; et 

- une memoire vive (102) comprenant des registres adaptes d 
memoriser les variables modiflees lors de I'execution dudit programme. 

21 . DIspositif de validation d'un document multimedia lors de la mise 
en oeuvre d'un service propose par un serveur d'un reseat^ de communication. 
Ie service etant d6crit dans un document de description d'un service conforme a 
I'une des revendications 1^11, caracterise en ce qu'il comprend : 
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- des moyens d'extracHon (100, 101, 102) d'une description de 
con.,.,ntes absfra^es assoc^es . un document n,u,tim^ia blnaire a pa* du 
document de description d'un sen/ice ; 

- 'f^' -""y^n^ cl'extraction (100, 101. 102) d'une description de 
5 contenuassooite audit document multimedia ;et cnP«on de 

- des moyens de comparaison (100, 101, 102) de ladite 
deso„pt,on .e contenu et de ,a description de cont^intes abst^ite el 
document de description d'un service. 

22. Dispositif de validation confomie a la revendication P1 
10 caracterls6encequHestlncorpor6dans: revendication 21. 

un microprocesseur (100) ; 

- "™ '"^'"oine morte (101) adapts i, mSmoriser un programme 
de validation d'un document multlmSdia ; et Prasramme 

15 m*,nn- ""^ "'^"""^ '^"2) comprenant des registms adapts 4 
15 --onser des variables modifl.es lorsde,. execution dudit programme 

en ce ou'L m""''!'!,"'""""' communication, caracteris. 

en ce qu,. compnend des moyens adapt^s ^ mett,« en ceuvre le p,x,c*de de 
validation confomie a I'une des revendieations 13 1, 18. 

20 .1 ^« ^""""nication. caractSris* en 

20 ce qu II comprend des moyens adapt^s , mettre en ceuv^ ,e procTd, de 
validation c»nfbnT,e I, l-une des ^'cations 13 . 18 

ce cull L'mnrrT""'"*"""" <»--'"'ca«°n, caract^ris. en 

ce qu.1 comprend des moyens adapt^s a mettre en ceuvre le proc^d* 
d'elabora«on d'une requite confomre , la revendication 12. 

26. Roseau de communication, caracteris^ en ce qu'il compr^nd de, 

30 conforme ^ la revendication 12. ^ ® 

28. IWoyens de stockage d'informations. eventuellement totatem^nt 
ou partiellement amovibles. Ilslbles oar ..n cvc.- • . totalement 

s. nsiDies par un systeme informatique. comprenant 
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- des moyens d'acquisitlon (100, 101. 102) du document 
multimedia ; 

- des moyens d'extractlon (100. 101. 102) d'une description de 
contraintes abstraites assocl6es d un document multimedia binaire ^ partir dudit 
document de description d'un service ; 

- des moyens d'extraction (100, 101. 102) d'une description de 
contenu assocfee audit document multimedia ; et 

- des moyens de comparaison (100, 101, 102) de ladite 
description de contenu et de la description de contraintes abstraites extraite du 
document de description d'un service. 

22. Dispositif de validation confomne § la revendicatlon 21. 
caract§ris§ en ce qu'il est incorpore dans : 

un microprocesseur (100) ; 

- une memoire morte (101) adapt6e 6 m6moriser un prograrfime 
de validation d'un document multimedia ; et 

- une m6moire vIve (102) comprenant des registres adapt^s S 
m6moriser des variables modlfl6es lors de I'execution dudit programme. ^ 

23. Ordlnateur-serveur d'un r^seau de communication, caracterise 
en ce qu'il comprend des moyens adapt6s ^ mettre en oeuvre le precede de 
validation cbnfomr^e d I'une des revendications 13^18. 

24. Ordinateur-cllent d'un r6seau de communication, caracterise en 
ce qu'il comprend des moyens adaptes ^ mettre en oeuvre le precede de 
validation conforme a I'une des revendications 13^18. 

25. Ordinateur-ciient d'un reseau de communication, caracterise en 
ce qu'il comprend des moyens adaptes ^ mettre en oeuvre le precede 
d'eiaboration d'une requete conforme ^ la revendicatlon 12. 

26. Reseau de communication, caract6ris6 en ce qu'il comprend des 
moyens adaptes S mettre en oeuvre le precede de validation conforme d I'une 
des revendications 13 ^ 18. 

27. Reseau de communication, caracterise en cq qu'li comprend des 
moyens adaptes S mettre en oeuvre le precede d'eiaboration d'une requete 
conforme d la revendicatlon 12. 
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des Instructions pour un programme Informatique adapt^es ^ mettre en ceuvre 
le precede de validation d'un document multimedia conforme a I'une des 
revendlcatlons 13 § 18. lorsque ce programme est charg6 et execute par le 
systdme informatique. 

29. Moyens de stockage d'informations. eventuellement totalement 
ou partiellement amovibles. lisibles par un systeme informatique. comprenant 
des instructions pour un programme informatique adaptees a mettre en ceuvre 
le proc§d§ d'elaboration d'une requ§te conforme ^ ia revendication 12. lorsque 
ce programme est charge et ex6cut6 par le systeme informatique. 

30. Programme d'ordinateur lisibie par un microprocesseu r, 
comprenant des portions de code logiclel adaptees § mettre en ceuvre le 
proc§d§ de validation d'un document multimedia confonne ^ I'une des 
revendlcatlons 13 ^ 18, lorsque ce programme d'orcllnateur est charge et 
execute par le microprocesseur. 

31. Programme d'ordinateur llsible par un microprocesseur. 
comprenant des portions de code logiciel adapt6es a mettre en ceuvre le 
proced6 d'6laboratlon d'un document multimedia conforme a la revendication 
12, lorsque ce programme d'ordinateur est charge et execute par le 
microprocesseur. 
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28. Moyens de stockage d'informations, 6ventuellement totalemenf 
ou partlellement amovibles, lisibles par un systeme informatique, comprenant 
des instructions pour un programme Informatique adapt§es a mettre en oeuvre 
le proc§d§ de validation d'un document multimedia conforme d Tune des 
revendicatlons 13 ^ 18, lorsque ce programme est charge et ex6cut§ par le 
syst§me informatique. 

29. IVloyens de stockage d'informations, 6ventuellement totalement 
ou partlellement amovibles. lisibles par un systeme informatique, comprenant 
des instructions pour un programme Infomriatique adaptees a mettre en oeuvre 
le precede d'elaboration d'une requ§te conforme a la revendication 12. lorsque 
ce programme est charge et execute par le systeme infonnatique. 

30. Programme d'ordlnateur lislble par un microprocesseur, 
comprenant des portions de code logiciel adapt6es a mettre en oeuvre ie 
proc6d§ de validation d'un document multimedia conforme ^ I'une des 
revendicatlons 13 gi 18, lorsque ce programme d'ordinateur est charge et 
execute par le microprocesseur. 

31. Programme d'ordinateur Iisibl6 par un microprocesseur, 
comprenant des portions de code logiciel adaptees § mettre en oeuvre fe 
precede d'elaboration d'un document multimedia conforme a la revendication 
12. lorsque ce programme d'ordinateur est charge et execute par le 
microprocesseur. 
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